14장. 끝까지 남는 설계 원칙

원문 14장 "결론"을 입문자용으로 다시 풀었다.
이 장은 새로운 기술을 배우는 장이 아니라, 책 전체의 설계 감각을 한 번에 묶는 장이다.

이 책은 처음부터 결합을 적으로 보지 않았다.

결합은 나쁜 것이 아니다.
소프트웨어 부품이 함께 일하려면 반드시 연결되어야 한다.

문제는 연결이 아니라 균형이다.

너무 강하게, 너무 멀리, 너무 자주 바뀌는 지식과 연결되면 고치기 힘들어진다.
반대로 필요한 연결까지 모두 끊으면 이해하기 어려운 구조가 된다.

14장의 핵심은 이것이다.

설계는 결합을 제거하는 일이 아니라, 책임에 맞게 결합을 배치하는 일이다.

0. 이 장의 새 단어

1. 이 장에서 딱 5가지만

1. 모듈성과 복잡성은 같은 연결을 반대 방향에서 본다.
2. 좋은 설계는 결합 제거가 아니라 결합 배치다.
3. 강한 지식은 가까이, 먼 연결은 약하게 둔다.
4. 자주 바뀌는 것은 흩어지지 않게 한다.
5. 설계 균형은 한 번이 아니라 계속 유지하는 것이다.

2. 모듈성과 복잡성은 서로 반대쪽 얼굴이다

모듈성은 좋게 들린다.
복잡성은 나쁘게 들린다.

하지만 둘은 완전히 다른 주제가 아니다.
같은 연결을 반대 방향에서 보는 말이다.

모듈성이 높다는 것은 이런 뜻이다.

• 한 부품을 이해할 때 다른 부품을 많이 몰라도 된다.
• 한 부품을 바꿀 때 변경이 멀리 퍼지지 않는다.
• 책임이 잘 나뉘어 있다.

복잡성이 높다는 것은 이런 뜻이다.

• 한 부품을 이해하려면 많은 곳을 함께 봐야 한다.
• 작은 변경이 예상 밖으로 퍼진다.
• 책임이 섞여 있다.

즉 모듈성은 "잘 나뉜 연결"이고, 복잡성은 "잘못 얽힌 연결"이다.

3. 결합은 접착제다

1장에서 배운 말로 돌아가자.

결합은 부품을 붙이는 접착제다.
접착제가 없으면 아무것도 함께 작동하지 않는다.

주문은 결제를 알아야 한다.
결제는 금액을 알아야 한다.
배송은 주소를 알아야 한다.
알림은 수신자를 알아야 한다.

연결이 있어야 시스템이 된다.

하지만 접착제가 아무 데나 너무 많이 묻으면 문제가 된다.

• 화면이 데이터베이스 내부를 안다.
• 결제 로직이 배송 정책을 안다.
• 알림 서비스가 사용자 전체 모델을 안다.
• 외부 API 형식이 핵심 도메인 안에 들어온다.

좋은 설계는 접착제를 없애는 것이 아니다.
붙일 곳에만 알맞게 붙이는 것이다.

4. 최종 공식 다시 읽기

원서의 결론을 대표하는 식은 이것이다.

BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

입문자 말로 다시 쓰면 이렇다.

강한 연결은 가까워야 한다.
먼 연결은 약해야 한다.
거의 안 바뀌는 것은 조금 덜 엄격해도 된다.
자주 바뀌는 것은 더 조심해야 한다.

이 식은 암기용이 아니다.
설계를 볼 때 질문을 잊지 않게 해주는 문장이다.

5. 책임으로 묶기

설계의 가장 중요한 질문 중 하나는 이것이다.

무엇을 기준으로 묶을 것인가?

비슷한 기술 역할로 묶을 수도 있다.

controllers/
services/
repositories/

같은 기능 책임으로 묶을 수도 있다.

orders/
payments/
shipping/

어느 쪽이 항상 옳은 것은 아니다.
하지만 책 전체의 관점은 분명하다.

함께 바뀌는 것, 같은 책임을 가진 것, 서로를 자세히 알아야 하는 것은 가까이 있어야 한다.

그리고 멀리 있는 것끼리는 내부를 공유하지 말고 안정적인 약속으로 연결해야 한다.

6. 글쓰기 비유로 이해하기

좋은 글은 단어를 아무 데나 흩어놓지 않는다.

관련 있는 단어는 문장 안에 모인다.
관련 있는 문장은 문단 안에 모인다.
관련 있는 문단은 장 안에 모인다.

소프트웨어도 비슷하다.

관련 있는 코드가 가까이 있으면 읽기 쉽다.
같은 책임의 코드가 한 덩어리로 있으면 바꾸기 쉽다.
멀리 있는 장끼리는 제목과 목차처럼 안정적인 연결이 필요하다.

좋은 글에서 단어 사이의 관계를 없앨 수 없듯이, 좋은 소프트웨어에서 결합을 없앨 수는 없다.
대신 관계를 읽기 좋게 배치한다.

7. 설계는 예측이 아니라 관찰과 조율이다

초보자는 좋은 설계를 "처음부터 정답을 맞히는 일"로 생각하기 쉽다.

하지만 현실에서는 요구사항이 바뀐다.
팀이 바뀐다.
외부 서비스가 바뀐다.
사용자가 늘어난다.
중요한 기능이 달라진다.

그래서 좋은 설계자는 처음부터 모든 미래를 맞히려 하지 않는다.

대신 관찰한다.

• 무엇이 반복해서 바뀌는가?
• 어떤 변경이 멀리 퍼지는가?
• 어떤 코드가 너무 많은 내부를 아는가?
• 어떤 추상화가 비용만 만들고 있는가?

그리고 필요한 만큼 조율한다.

8. 책 전체를 한 장으로 접으면

이 표의 답은 결국 하나로 모인다.

책임에 맞게 연결하라.

9. 좋은 설계 판단문

설계 토론에서 다음 문장을 사용해보자.

1. "이 연결은 강하지만 가까우니 괜찮습니다."
2. "이 연결은 멀기 때문에 내부 구조 대신 계약이 필요합니다."
3. "이 규칙은 자주 바뀌므로 한곳에 모아야 합니다."
4. "이 추상화는 변동성이 낮은 곳에는 과할 수 있습니다."
5. "이 두 파일은 함께 자주 바뀌므로 거리를 줄이는 편이 낫습니다."
6. "이 서비스는 필요 이상의 모델 지식을 알고 있습니다."

이 문장들은 취향 싸움을 줄인다.

"이게 더 깔끔해 보여요"보다 낫다.
세기, 거리, 변동성으로 이유를 말하기 때문이다.

10. 결론

이 책이 남기는 가장 중요한 태도는 균형이다.

결합을 두려워하지 말자.
하지만 결합이 어디에 있고, 얼마나 강하고, 얼마나 멀고, 얼마나 자주 바뀌는지 보자.

강한 지식은 가까이 둔다.
먼 연결은 약하게 만든다.
자주 바뀌는 지식은 흩어지지 않게 한다.
거의 바뀌지 않는 작은 코드는 단순하게 둔다.
균형이 깨지면 다시 맞춘다.

소프트웨어 설계는 완벽한 벽을 세우는 일이 아니다.
변화 속에서도 이해하고 고칠 수 있는 연결을 만드는 일이다.

더 해보기

1. 이 책에서 가장 기억에 남는 연결 하나를 골라보자.
2. 현재 프로젝트에서 "강하고 멀고 자주 바뀌는" 연결이 있는지 찾아보자.
3. 그 연결을 가까이 모을지, 약하게 만들지, 변동성을 격리할지 한 문장으로 적어보자.

연습문제

1. 설명. 끝까지 남는 설계 원칙의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
2. 구분. 두 개념(원칙, 규칙)을 실제 예시 하나로 구분하라.
3. 적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

부록 B. 헷갈리는 개념 비교표

부록 C. 더 읽을 자료

• 이 장의 더 해보기 섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다.
• 같은 책의 0장 한눈에 보기 — 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다.
• 원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
• 이 장의 flashcards.json — 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.

부록 D. 연습문제 풀이

1. 설명 예시. 끝까지 남는 설계 원칙는 변경이 어디로 번지는지 보고, 필요한 연결과 줄여야 할 연결을 구분하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
2. 구분 예시. 두 개념(원칙, 규칙)의 차이는 이렇게 잡으면 된다. 원칙은 상황 판단의 기준이고, 규칙은 그대로 따르는 절차에 가깝다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
3. 적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.